are you sure we need this check to have all these conditions? isn't checking isOwner enough? the checks here look the same like what is already done inside resolveSessionOwnership()

are we sure it's only MAIN dataset? what about others datasets that are sent over LLM like atd-unmuted, atd-active?
We already have LLM_DATASET_NAMES defined that contains them, maybe it should be used here?

this code here handles the case when we call resetHeartbeatWatchdogs() for main and LLM is not connected, but what about the case when LLM is not connected yet, but it is connecting and later when it becomes connected, we will end up with no heartbeat watchdog. I think we need to check if we need to restart any heartbeat watchdogs when LLM changes from "not connected" to "connected".

Cover all LLM-backed watchdogs

When LLM is disconnected in a webinar/panelist meeting where atd-active or atd-unmuted is visible, this DataSetNames.MAIN guard leaves their watchdogs armed even though those datasets are also LLM-delivered (LLM_DATASET_NAMES includes them). Their timers will still expire and re-enqueue /sync repeatedly while the channel is down, so the no-LLM suppression only fixes main; use the LLM dataset set here instead of the single dataset check.

Useful? React with 👍 / 👎.

as discussed 1-1 on webex, we'll need to change this to check if we expect LLM to be connected instead of checking if it is actually connected

Use actual LLM channel state

When the LLM websocket drops while the meeting is still joined (for example, connect failed or the socket is reconnecting), joinedWith.state remains JOINED, so this callback reports true and the new watchdog guard still arms the main timer and keeps issuing /sync even though no LLM messages can arrive. Meeting#updateLLMConnection already treats joined state and webex.internal.llm.isConnected() as separate values, so pass the actual connection/ownership state here, or combine it with joined state, instead of using joinedWith alone.

Useful? React with 👍 / 👎.

Suppress already-armed LLM watchdogs

When LLM becomes not expected after an LLM dataset watchdog has already been scheduled, no further LLM dataset message is guaranteed to arrive and re-enter this guard, so the existing timeout still fires and enqueues /sync before the guard is evaluated again. In that path performSync() also restarts the root-hash sync timer, so the no-LLM case can continue issuing syncs; the expectation check needs to run in the timeout/enqueue path or LLM timers need to be cleared when the meeting stops expecting LLM.

Useful? React with 👍 / 👎.